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ABSTRACT 



A data file is regarded as a digital package. A conventional 
interface is provided for scheduling pickup and delivery of 
the data file*via-one=or=more a satellitccommunications,links^ 
The^to^file = may 3 represenTvari^^ 

c such=as=text,4magesraudio^or^video.,A.centralized system 
receives the schedulmg^order^andcarranges.^Jhe^daU^nle 
to^be c automaticaliy = picked D up°from c one-or*more=locations 
and~delivered~to~one-or-more-destinations. JThe delivery 
service may include buffermg^me^da^^le^for^A Piedeter- 
mmed^Ume-period-to*complyjwith Q me^scheduled^delivery 
time.^TlieTc^ 

mation notice for the scheduled pickup and delivery, and 
also provides notice that the data file was actually delivered. 
The centralized system maintains an activity log useful for 
status inquiry and billing. In short, the centralized system 
functions as a "dispatcher" for bits, within an infrastructure 
for receiving, tracking, delivery and billing based on bits. 

8 Claims, 4 Drawing Sheets 
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PICKUP AND DELIVERY OF DATA FILES DETAILED DESCRIPTION OF THE 

PREFERRED EMBODIMENTS 



BACKGROUND OF THE INVENTION 

The present invention relates to a method and system for 
data file pickup and delivery, and, more particularly, is 
directed to a centralized system including a satellite link for 
delivering data files in accordance with instructions by a 
user through a screen-based interface. 

As the popularity of the Internet increases, there is a 
commensurate increase in the need to deliver content over 
large distances, bypassing clogged communication chan- 
nels. Sometimes content must be delivered according to a 
specified schedule that may be one-time or recurring. This 
need is particularly critical for files which must be delivered 
in a real time or near real time sequence, such as audio and 
video files, and for files which must be delivered at the same 
time to a multiplicity of places. A similar situation exists for 
data streamed during delivery. 

There is also a need for an automated interface by which 
a user can schedule and manage transfer of data files, so that 
file transfer services can be provided in a highly cost- 
effective manner. 

SUMMARY OF THE INVENTION 

In accordance with an aspect of this invention, there are 
provided a method of and a system for transmitting a file 
using a satellite communications link in accordance with a 
scheduling order specifying pickup and delivery instructions 
for the file. 

According to a further aspect of the invention, the sched- 
uling order is received from a user, the scheduling order also 
specifying at least one location and time for retrieval of the 
file. 

In accordance with another aspect of this invention, there 
is provided a user interface for scheduling a file transfer, 
comprising a terminal for displaying a data screen to the a 
user, the data screen including fields for specifying a file 
location, size, pickup time and delivery time, and means for 
sending information entered through the data screen to a 
central system. 

In accordance with another aspect of this invention, there 
are provided a method and a system for receiving a file that 
has been transmitted using a satellite communications link in 
accordance with a scheduling order specifying pickup and 
delivery instructions for the file. 

According to a further aspect of the invention, this file is 
transmitted by multicasting, and delivery availability 
according to the scheduling order is confirmed before the file 
is received. 

It is not intended that the invention be summarized here 
in its entirety. Rather, further features, aspects and advan- 
tages of the invention are set forth in or are apparent from 
the following description and drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram illustrating an environment in 
which the present invention is applied; 

FIG. 2 is a flowchart illustrating data file pickup and 
delivery according to the present invention; 

FIG. 3 is a chart showing a screen for customer registra- 
tion; and 

FIG. 4 is a chart showing a screen for scheduling data file 
pickup and delivery. 



The present technique regards a data file as a digital 
package, and provides a convenient interface for scheduling 

5 pickup and delivery of the data file via one or more satellite 
communication links. The data file may represent various 
types of information, such as text, images, audio or video. A 
centralized system receives the scheduling order and 
arranges for the data file to be automatically picked up from 

10 one or more locations and delivered to one or more desti- 
nations. The delivery service may include buffering the data 
file for a predetermined time period to comply with the 
scheduled delivery time. The centralized system provides a 
scheduling confirmation notice for the scheduled pickup and 

15 delivery, and also provides notice that the data file was 
actually delivered. The centralized system maintains an 
activity log useful for status inquiry and billing. In short, the 
centralized system functions as a "dispatcher" for bits, 
within an infrastructure for receiving, tracking, delivering 

20 and billing based on bits. 

The centralized system provides comprehensive manage- 
ment of communication channel capacity, particularly in the 
space segment. Multiple satellites may provide capacity on 
an ongoing basis, with capacity available on additional 

25 satellites during peak demand. The centralized system also 
efficiently manages capacity on inter-satellite links, if any. 

The present technique also provides a user with an easy to 
use screen -based interface for scheduling data file pickup 

30 and delivery without the burden of managing communica- 
tions, capacity. The user interface also allows the user to 
track the progress of the data file from its source(s) to its 
destination(s). 

Referring now to the drawings, and in particular to FIG. 

35 1, there is illustrated an environment in which the present 
invention is applied. FIG. l^showscommunication satellites 
10,-tlrinter-satellite4ink^r4, satellite links 15-1 6, 17rl8,' 
^19pterrestrial network 20, earth stations 30, 31, 35A, 35B, 
35C, controllers 40, 45, data buses 42, 47, transmitter 50, 

40 receiver 55, data^storage^uni^O^S, gateway-70, client 75, 
sending customer terminal 80, service provider premises 90 
and customer premises 92, 95. 

Generally, terrestrial links are assumed to operate in a 
duplex handshaking manner. Satellite links typically operate 

45 in simplex mode although a return link is sometimes con- 
figured via a terrestrial or other satellite link. 

Communications satellites 10 and 11 are preferably in 
geostationary orbit. Other orbits may be used, and those of 
ordinary skill in the art will understand the additional 

50 communications overhead needed to communicate with 
satellites in other than geostationary orbit. Satellite 10 is 
adapted to receive information on uplink 15 from earth 
station 30 and to transmit the received information on 
downlink 16 covering earth station 35A. This is referred to 

55 as a forward channel. In some embodiments, satellite 10 is 
also adapted to receive information from earth station 35A 
on a second uplink and to transmit the received information 
on a second downlink to earth station 30. This is referred to 
as a reverse channel. It will be appreciated that the actual 

60 communication channel may be the same for the first and 
second uplinks and downlinks, respectively, and can be 
re -used. 

Satellite U is adapted to receive information on uplink 17 
from earth station 31 and to transmit the received informa- 
65 tion on a downlink covering earth stations 35B, 35C. For 
clarity, the downlink from satellite 11 is depicted as down- 
links 18, 19, although it will be understood that the infor- 
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mation on each of these downlinks is identical. In some 
embodiments, satellite 11 is also adapted to transmit from 
earth stations 35B, 35C to earth station 31. 

In the embodiment shown in FIG. 1, satellites 10 and 11 
communicate directly with each other via inter-satellite link 5 
14. For example, to transmit from earth station 30 to earth 
station 35 C, the best path may be via uplink 15, inter- 
satellite link 14 and downlink 19. 

Earth stations 30, 31 and 35A-35C each include an 
^antenna=forcommiinicating'With=one , 'of satellites^lO^nd-ll^l? 
and c approprkte^electronics?for-eon^ 

band electricaLsignaLajid,a,rao^o c frequ^cy=signal, r su^h : as^ 
m Ka,-Ku- or <3^b andF* 

Terrestrial network 20 encompasses the public switched 
telephone network (PSTN) including wireline and wireless 15 
links, the Internet and any private wireline and wireless 
terrestrial communication channels established for commu- 
nication between controllers 40 and 45. 

For brevity, only the configurations coupled to earth ^ 
stations 30 and 35A will be discussed. In practice, many 
earth stations communicate with many satellites in the 
manner discussed below. 

The transmitting configuration for an earth station will 
now be discussed. Earth station 30 is an example of a 25 
transmitting earth station. 

Sending customer terminal 80 is a general purpose 
processor, such as a personal computer, personal digital 
assistant or the like. Customer terminal 80 is coupled to 
controller 40 via an appropriate communication channel, 30 
such as a dedicated communication line, a local area 
network, a dial-up communication line, an Internet packet 
switched channel and so on. Sending customer terminal 80 
is adapted to provide a screen-based interface for entering 
scheduling orders for data file pickup and delivery, to 35 
receive notices from the central system relating to the 
scheduled pickup and delivery services, and to provide a 
data file for pickup. The data file may represent various types 
of information, such as text, images, audio or video. The 
data files may be delivered via Internet file transfer protocol 40 
(FTP), transmission control protocol (TCP), user datagram 
protocol (UDP) and so on. 

In one embodiment, the screen-based interface is pro- 
vided via access to an Internet web site. In another 
embodiment, additional software for practicing the present 45 
technique is operative in customer terminal 80 for providing 
the screen-based interface. In some embodiments, the web 
site or additional software is activated by clicking on an icon 
on a virtual desktop. 

Gateway 70 is a general purpose processor is coupled to 50 
controller 40 and data storage unit 60 via data bus 42. In 
some embodiments, gateway 70 is controlled by the sending 
customer although it is physically at the service provider's 
premises. Gateway 70 functions to receive a data file from 
data storage unit 60 in response to an instruction from 55 
controller 40, to convert the format of the received data file 
to a different format in response to another instruction from 
controller 40, and to provide the retrieved data file, as 
selectively converted, to transmitter 50. 

In one embodiment, ^e^ayW70^cts^ = i c "dif ital- videos 60 
broadcast (D\0})/inte7ne^^ 

the conversion from £ IJ^pj^toj^,D^B/MEEG5lI r paekets^ 
Standards defining these conversions include "DVB Speci- 
fication for Data Broadcasting" (EN 301 192), "Digital 
Video Broadcasting: Specification for Service Information 65 
in DVB systems" (EN 300 468), "DVB Guidelines on 
Implementation and Usage of Service Information" (ETR 
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211), "Extension for Digital Storage Media Command and 
Control (DSM-CQ-International Standard (IS)" (ISO/IEC 
13818-6), and so on. All of these standards are available at 
www.dvb.org. 

Compliance with the DVB data broadcast standard 
requires an ability to perform Multiprotocol Encapsulation 
(MPE). MPE defines how communication protocols in the 
form of datagrams are encapsulated in DSM-CC sections 
that comply with, for example, the MPEG-II Transport 
Stream packet format (ISO/IEC 13818-1). Compliance with 
EN 300 468 requires insertion of service information data 
for self configuration as specified by ETS 300 468 so that 
program information allowing receivers to automatically 
tune themselves to the correct parameters can be placed into 
MPEG transponder streams. 

Although use of DVB is described herein, it will be 
understood that other protocols may be used such as asyn- 
chronous transfer mode (ATM). 

Gateway 70 is adapted to output multiple program IDs 
simultaneously, so that the central system can put multiple 
services into a single uplink stream and segment bandwidth 
for each customer and service. Gateway 70 supports IP 
unicasting, IP multicasting and broadcasting. It also supports 
IP static and dynamic routing. 

Data storage unit 60 is a magnetic, optical, transistor, 
magneto-optical or other high capacity storage medium, and 
is coupled to gateway 70 and controller 40 via data bus 42. 
Data storage unit 60 functions to store data files supplied 
thereto from controller 40 and to provide the stored files to 
gateway 70 in accordance with control commands from 
controller 40. 

Transmitter 50 is a communication device such as a 
modem, and is coupled to earth station 30, controller 40 and 
gateway 70. Transmitter-50?is*adaptedjto*receive^filesffTom^ 
gateway J70„and3toaprovide-these^ 

transmission on uplinklSitOiSateULteslOfm.accorda^ceiwithi 
msuTietions_frpm^c^troUej^40. In practice, many transmit- 
ters may bemused for each satellite, depending on the 
frequencies of the uplinks and downlinks on the satellite. 
The specific transmitter details are known to those of 
ordinary skill in the art and are omitted here for brevity. 

Controller 40 is a general purpose computer programmed 
according to the present technique, and is coupled to sending 
customer terminal 80, gateway 70, data storage unit 60, 
transmitter 50 and terrestrial network 20 via appropriate 
communication channels. Controller 40 is adapted to receive 
scheduling orders for data file pickup and delivery from 
customer terminal 80 and to send status notices to customer 
terminal 80. Controller 40 is further adapted to retrieve a 
data file from customer terminal 80 and transfer it to data 
storage unit 60; to instruct data storage unit 60 to receive and 
provide information; and to instruct data storage unit to 60 
supply a data file to gateway 70. Controller 40 is additionally 
adapted to communicate with controller 45 to schedule data 
file delivery and receive notices from controller 45 relating 
to delivered data files. When retrieving a data file from 
customer terminal 80, controller 40 serves as a firewall. 

The receiving configuration for an earth station will now 
be discussed. Earth station 35A is an example of a receiving 
earth station. 

Receiver 55 functions as a standalone DVB/IP receiver, 
including a channel interface, a demodulator, a forward error 
detection/correction unit and a DVB demultiplexer. The 
multiplexed DVB signal may contain multiple program IDs, 
for carrying unicast, multicast and broadcast traffic. 
Receiver 55 performs program ID filtering, and router-type 
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filtering, that is, receiver 55 only forwards multicast IP 
subnetwork traffic for destinations coupled thereto and dis- 
cards the remainder, in accordance with Internet Group 
Management Protocol (IGMP). In other embodiments, 
receiver 55 operates according to a format other than DVB. 

Data storage unit 65 functions in a similar manner as data 
storage unit 60, and will not be described further for brevity. 

Client 75 is a general purpose computer coupled to 
receiver 55, data storage unit 65 and controller 45. Client 75 
is the destination for a data file transmitted from customer 
terminal 80. Client 75 is adapted to receive data files from 
data storage unit 65, In some embodiments, client 75 
receives data files directly from receiver 55. 

FIG. 1 shows client 75 and earth station 35 A co-located 
at customer premises 95. In another embodiment, earth 
station 35A is located at service provider destination pre- 
mises while the functionality of client 75 is split between the 
service provider destination premises and the customer 
destination premises. 

Controller 45 is coupled to client 75, data storage unit 65, 
receiver 55 and terrestrial network 20 via appropriate com- 
munication channels. Controller 45 is adapted to receive 
scheduling requests for data file delivery from controller 40 
via terrestrial network 20, to respond thereto based on 
facilities availability, to notify receiving customer terminal 
of a scheduled delivery, to receive confirmation from client 
75 that a data file has been delivered thereto, and to send 
notices to controller 40 confirming data file delivery. Con- 
troller 45 is further adapted to instruct receiver 55 to receive 
a data file from earth station 35 A that has been transmitted 
on downlink 16 from satellite 10 and convert the format of 
the data file, to instruct data storage unit 65 to receive and 
provide information, and to instruct client 75 to receive a 
data file from data storage unit 65. 

FIG. 2 is a flowchart illustrating data file pickup and 
delivery. FIG. 2 shows activity occurring at four places: 
"SEND CUSP* — meaning sending customer terminal 80, 
"NET XMT" — also referred to as the system transmitter — 
meaning earth station 30, controller 40, data storage unit 60 40 
and gateway 70, "NET RCV"— also referred to as the 
system receiver — meaning earth station 35A, controller 45, 
receiver 55 and data storage unit 65, and "RCV CUST"— 
meaning client 75. In FIG. 2, horizontal arrows indicate 
transmission of information between locations, and the 
vertical direction indicates time. 

It is assumed that a user has already registered with the 
central system. FIG. 3, discussed below, is an example of a 
screen-based interface used for registration. 

The process of file pick up and delivery is discussed in 
detail below. As an overview, at the scheduled pickup time, 
the data file is sent from customer terminal 80 to controller 
40. If necessary, other portions of the data file are sent from 
other customer locations to controller 40. Controller 40 
stores the data file in data storage unit 60. When it is time for 
the data file to be transmitted, controller 40 retrieves the data 
file from data storage unit 60 and transfers the data file to 
gateway 70 that converts the file format, for example, to 
DVB/MPEG II format, and delivers the converted data file 
to transmitter 50. 

At the receiving side, receiver 55 receives the data file via 
downlink 16, converts its format in accordance with the 
scheduled delivery instructions as applied by controller 45, 
and delivers the converted data file to client 75. Appropriate 
acknowledgement and reporting to controller 40 occurs 
through the path of the data file so that its progress can be 
readily monitored. 
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At step 100, a user at sending customer terminal 80 
submits a scheduling order for file pickup and delivery. FIG. 
4, discussed below, is an example of a screen-based interface 
for creation of a scheduling order. 

At step 102, controller 40 of the system transmitter 
receives the scheduling order. At step 104, controller 40 
checks whether facilities are available to transmit the data 
file by contacting the appropriate ones of gateway 70 and 
controller 45. Together, controllers 40 and 45 schedule 
transmission capacity and storage capacity at the transmit- 
ting and receiving sides of satellite 10. Generally, storage 
and conversion of a data file, as needed, occurs as the 
transmitting side. In some situations, depending on facilities 
availability, it may be preferable to store and/or convert the 
data file at the receiving side. 

At step 103, controller 45 receives the availability check 
and determines whether it can comply with the requested 
data file transfer. Generally, the determination is positive, 
and at step 105, controller 45 confirms availability, and at 
step 107 prepares and sends a delivery notice to client 75 
providing notice of a future data file delivery. If the deter- 
mination is negative, then controller 45 replies with what it 
can accomplish, and controller 40 may send a new avail- 
ability check. In some embodiments, a delivery notice is not 
sent to receiving client 75. 

At step 106, controller 40 receives a positive availability 
reply from controller 45, enqueues the file pickup and 
delivery order, and, at step 108, prepares and sends an order 
confirmation notice to customer terminal 80. At step 110, 
customer terminal 80 receives the confirmation notice. 

In some embodiments, customer terminal 80 is coupled to 
controller 40 via an Internet connection, and the confirma- 
tion notice is received while the user is still at the web site 
in communication with controller 40. In one case, controller 
40 is also operative as a web server. In another case, 
controller 40 is contacted by one or more web servers and 
provides hypertext transfer protocol (HTTP) responses to 
the web server. In a farther case, the confirmation notice is 
sent as an electronic mail (e-mail) message to an e-mail 
account specified during registration. 

In other embodiments, customer terminal 80 is coupled to 
controller 40 via a circuit switched connection, and the 
confirmation notice is received while the user is still at 
controller 40, or is sent to an e-mail account specified during 
registration. 

When it is time for the file to be picked up, at step 120, 
controller 40 obtains the data file from customer terminal 80 
via an appropriate communication channel such as the 
Internet. At step 122, customer terminal 80 receives the file 
pickup request, and at step 124, provides the requested file. 
At step 126, controller 40 receives the retrieved data file and 
stores the retrieved file in data storage unit 60. 

In some embodiments, instead of picking up the file 
electronically, the user, also referred to as the customer, may 
send the file to controller 40 on a disk or other portable 
media in advance of the scheduled pickup time. In some 
cases, the data file to be picked up is at a customer location 
(not shown) other than customer terminal 80, such as at a 
transmitting video camera. In cases where portions of the 
data file are obtained from different locations, a different 
pick up method may be used at each location. 

In some embodiments, the customer can schedule a file 
pickup, and then schedule delivery of the file at a later time 
such as after the file has been picked up. 

At step 130, controller 40 instructs gateway 70 to convert 
the format of the stored data file, as needed, such as by 
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separating it into datagram sized packets, separating it into customer terminal 80, the format and size of the file to be 

multicast formatted packets or converting a file into a picked up, the time of pick up, the frequency of pickup and 

DVB/MPEG format file. Format conversion may be the priority of the pickup. For example, a news video file has 

required to comply with the pickup and delivery instruc- real-time priority, while low priority may be appropriate for 

tions. Format conversion may be required by internal service 5 a financial log or historical video file. The frequency may be 

provider transmission format requirements. Other format daily, once a week, once a hour and so on. 

conversions will be apparent to those of ordinary skill. Customers who do not wish to have a regular file pickup 

x^Atrstep 132, r contfoUeT~40 z mstructe and delivery simply omit default shipping instructions. 

[j ransmit the data file, as converted, on uplink 15 to satellite j fig. 4 is a chart showing scheduling order screen 170 for 

U0. The transmission time is selected in view of facility: 10 scne d u Ung data file pickup and delivery, either on a recur- 

\ availability, as scheduled at steps 103-106, and can be ring basis or as a one-time event. Scheduling order screen 

j substantially befor e the scheduled data file delivery time! 170 includes data entry fields for the customer's account 

jThat%pfiirbuffering can tfe performed-innhe-transmitside. n ame and password, for specification of payment informa- 

(or.t^re^eiy^sidA^ tion if other than the default payment method specified at 

^O^and^S.^heOsdataiStorage^unit^S is 3 usedWa -tefnporM' ^ registration is to be used, for identifying the characteristics 

^l^^^^^^* 10134 ^ 0 ^' ''^J^^^^~ — of the data file to be picked up, and its pickup time and 

^Afstep 133, receiver 55 receives the transmitted data file. frequency, and for identifying the destination(s) of the data 

In response to instructions from controller 45, at step 135, file. The chart in FIG. 4 is merely an illustrative example of 

receiver 55 converts the format of the data file and stores the scheduling order screen 170; other designs and fields will be 

data file in data storage unit 65. 20 apparent to those of ordinary skill in the art. 

When it is time for the file to be delivered, at step 137, As mentioned above, in some embodiments, within a 

server 45 instructs data storage unit 65 to provide the data short time after clicking on submit button 171, a user may 

file to client 75. At the completion of the file delivery, client get a scheduling confirmation for the data file pickup. In 

75 provides a delivery confirmation notice to controller 45. 25 other embodiments, the scheduling confirmation is e-mailed 

At step 141, controller 45 provides a delivery confirma- 10 the US&T - 

tion notice to controller 40. In one embodiment, the delivery Screens (not shown) are also provided for checking on the 

confirmation notice is sent via terrestrial network 20. In status of a scheduled data file pickup, and for modifying a 

another embodiment, the delivery confirmation notice is sent scheduled data file pickup. 

via a second uplink (not shown) from earth station 35A to 30 xh e screen-based interface described herein allows a user 

satellite 10 and then on a second downlink (not shown) to to manage pick up and delivery of their files without concern 

earth station 30. f or managing the communication facilities that actually 

At step 142, controller 40 forwards the delivery confir- transmit and receive the data files. Accordingly, the user's 

mation notice to customer terminal 80, such as by e-mail or network management burden is reduced, 

facsimile transmission. At step 144, customer terminal 80 35 xh e pre sent technique has been described with reference 

receives the delivery confirmation notice. At step 146, to a screen-based interface. In a modification, the user 

controller 40 records the successful file delivery in a log for device may be based on audible presentation of information 

management and accounting purposes. instead of visual, such as a telephone or terminal providing 

In some embodiments, controller 40 also logs the progress voice synthesis, 

of the file through the central system at other points so that 40 Th e system of FIG. 1 is useful for multicasting, distrib- 

a user can check the location and status of the file using, for u ^ hosting and network caching. 

example, a screen-based interface (not shown). MulUcasting is a session layer protocol built on top of 

In some embodiments, client 75 employs a screen-based User Datagram Protocol (UDP). It uses Class D address 

interface, provided in a similar manner as the screen-based ^ space) f rom 224.0.0.0 through 239.255.255.255, to send data 

interface of sending customer terminal 80, that enables client ftom one host to multiple hosts. A receive host sends an 

75 to request inclusion in a multicast group from controller IGMP join message to routers, or equivalent devices, so that 

40 via controller 45 and terrestrial network 20 or other the routers will forward the traffic to the receiving host, 

suitable communications channel. Multicast software for delivering content reliably in a sat- 

FIG. 3 is a chart showing registration screen 150 for 5Q ellite environment includes OMNICAST (™) available from 

customer registration. This screen is provided to terminal 80, StarBurst Communications in Concord, Mass., and FAZCT 

for example, when terminal 80 is in communication with an (™), available from KenCast Software in Stamford, Conn. 

Internet web site, or has otherwise established a connection Additional information on these products is available at 

with controller 40. In some embodiments, a separate regis- www.starburstcom.com and www.kencast.com. OMNI- 

tration processor is used instead of controller 40. 5J CAST uses a StarBurst proprietary Multicast File Transfer 

Registration screen 150 contains fields for entry of the Protocol (MFTP) to deliver files to multiple locations, 

customer's account name, password, e-mail address, billing Distributed hosting refers to storing content from a web 

information and default file pickup and delivery instructions. site at multiple sites so that the content is closer to a 

Billing information includes a physical address and payment requesting end user, and thus can be delivered faster. The 

means, such as a credit card or authorized credit account. 60 system receivers of FIG. 1 are appropriate for supporting 

The chart in FIG. 3 is merely an illustrative example of distributed hosting. 

registration screen 150; other designs and fields will be Network caching refers to a configuration wherein data is 

apparent to those of ordinary skill in the art. stored in caches at various locations, and provided directly 

Some customers may wish to schedule a regular file from these locations, thereby eliminating the need to go back 

pickup and delivery, for example, a daily corporate news 65 to a central source. Network caching conserves network 

broadcast. Registration screen 150 allows the customer to bandwidth and reduces the processing load on the central 

specify the file pickup place or places, such as a directory on host. More recent Internet applications are employing cache 
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processing, wherein the cache performs functions based on 
the content stored therein, such as "playing 1 ' streaming video 
from the cache, providing billing information for pay per 
view content, modifying file identifiers for ad insertion, and 
sending run -time commands to a user for streaming soft- 5 
ware. The system receivers of FIG. 1 are appropriate for 
supporting distributed hosting. 

The system of FIG. 1 allows a user to create new files, 
update existing files or delete files at a master site, and have 
these changes automatically reflected at updates to a set of 10 
child sites. Controllers 40 and 45 cooperate to provide 
version control and backup at all sites, automatic restoration 
of damaged files, priority updating, tailoring data at remote 
sites, support of multiple operating systems and hardware 
configurations and remote verification. 1 5 

Although the present technique has been described with 
regard to data files, one of ordinary skill in the art will 
appreciate that the system configuration may also be used 
for streaming video with suitable modifications to the soft- 
ware described above. 20 

Streaming video refers to separating a video signal into 
packets which are then sent over the Internet, for example, 
and reassembled and displayed at the destination in real 
time. Protocols relevant to streaming video include the 25 
Internet Engineering Task Force (IETF) Real Time Transfer 
Protocol (RTP) (available as Request for Comments (RFC) 
1889), Real Time Control Protocol (RTCP) (available as 
RFC 1890) and Real Time Streaming Protocol (RTSP) 
(available as RFC 2326). All RFCs are available at www.i- 3Q 
etf.org. 

Although an illustrative embodiment of the present 
invention, and various modifications thereof, have been 
described in detail herein with reference to the accompany- 
ing drawings, it is to be understood that the invention is not 35 
limited to this precise embodiment and the described 
modifications, and that various changes and further modi- 
fications may be effected therein by one skilled in the art 
without departing from the scope or spirit of the invention as 
defined in the appended claims. 40 

What is claimed is: 

1. A method for file transfer, comprising: 
transmitting a file using a satellite communications link in 

accordance with a scheduling order created by a sender 
specifying pickup and delivery instructions for the file 45 
and further comprising sending a delivery notice to a 
destination for the file before transmitting the file. 

2. A system for file transfer, comprising: 

a transmitter for transmitting a file using a satellite 
communications link in accordance with a scheduling 50 
order created by a sender specifying pickup and deliv- 
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ery instructions for the file and further comprising 
means for sending a delivery notice to a destination for 
the file before transmitting the file. 

3. A method for file transfer, comprising: 
transmitting a file using a satellite communications link in 

accordance with a scheduling order created by a sender 
using a screen-based interface specifying pickup and 
delivery instructions for the file and further comprising 
sending a delivery notice to a destination for the file 
before transmitting the file. 

4. A system for file transfer, comprising: 

a transmitter for transmitting a file using a satellite 
communications link in accordance with a scheduling 
order created by a sender using a screen-based interface 
specifying pickup and delivery instructions for the file 
and further comprising means for sending a delivery 
notice to a destination for the file before transmitting 
the file. 

5. A method for file transfer, comprising: 
transmitting a file using a satellite communications link in 

accordance with a scheduling order created by a sender 
using specifying pickup and delivery instructions for 
the file and where a delivery notice is sent to a 
destination for the file at approximately the time that 
the scheduling order is received. 

6. A system for file transfer, comprising: 

a transmitter for transmitting a file using a satellite 
communications link in accordance with a scheduling 
order created by a sender specifying pickup and deliv- 
ery instructions for the file where a delivery notice is 
sent to a destination for the file at approximately the 
time that the scheduling order is received. 

7. A method for file transfer, comprising: 
transmitting a file using a satellite communications link in 

accordance with a scheduling order created by a sender 
using a screen-based interface specifying pickup and 
delivery instructions for the file and where a delivery 
notice is sent to a destination for the file at approxi- 
mately the time that the scheduling order is received. 

8. A system for file transfer, comprising: 

a transmitter for transmitting a file using a satellite 
communications link in accordance with a scheduling 
order created by a sender using a screen-based interface 
specifying pickup and delivery instructions for the file 
where a delivery notice is sent to a destination for the 
file at approximately the time that the scheduling order 
is received. 

* * * * * 
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